home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / March 96 / RE>Re Patching ODWindowState < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  4.6 KB  |  [TEXT/ttxt]
  1. Subject:     RE>Re: Patching ODWindowState
  2. Sent:        3/12/96 3:09 PM
  3. Received:    3/12/96 2:21 PM
  4. From:        Rob Cope, rob@eclipse.cpcn.com
  5. Reply-To:    OpenDoc-Interest@CILabs.ORG
  6. To:          OpenDoc Related Technologies Interest List, OpenDoc-Interest@CILabs
  7.  
  8.  
  9.                                                                  Date: 3/12/96
  10. Subject:  RE>Re: Patching ODWindowState                         Time:  3:24 PM
  11. Troy,
  12.  
  13. Thank you for your speedy reply.  As you can imagine, that wasn't what I wanted to here, but it is better than hearing nothing.  I am trying to implement menus that are available not only when my part is active, but also when parts embedded in my part are active.  I think I have figured out a way to get it to work by only replacing the menu DispatchModule, however.
  14.  
  15. >I was one of the first people to write a patch for OpenDoc here, and I 
  16. >discovered these problems.  Unfortunately, there was not time to do 
  17. >anything about them.
  18.  
  19. You might consider at least changing the recipe before the next release :)
  20.  
  21. Thanks,
  22.  
  23. Rob Cope
  24. Eclipse Services
  25.  
  26.  
  27. --------------------------------------
  28. Date: 3/12/96 3:06 PM
  29. To: Rob Cope
  30. From: Troy Gaul
  31. I knew there would be a question about patching and this problem 
  32. eventually...
  33.  
  34. >Following the "Patching OpenDoc" recipe on DR4, I created a replacement 
  35. >for the WindowState object.  Here is a code snippet that shows how I 
  36. >create it:
  37. >
  38. >    ODWindowState *realWindowState = session->GetWindowState(ev);
  39. >    
  40. >    OLWindowState *newWindowState = new OLWindowState;
  41. >    newWindowState->InitOLWindowState(ev, realWindowState);
  42. >    
  43. >    session->SetWindowState(ev, newWindowState);
  44. >
  45. >My OLWindowState object overrides every method defined in OpenDoc's 
  46. >WinStat.idl.  Currently, every method but somInit and somUninit just calls 
  47. >the realWindowState object to do the work.  This works fine until I close 
  48. >my part, when I get a SOM error, kODErrInvalidFrame.  Here is an excerpt 
  49. >from the SOM trace at the point of the error.
  50. >
  51. ..
  52. >
  53. >Notice that two methods of ODWindowState, ODWindowStateAddIterator, and 
  54. >ODWindowStateNext, are being called that were not overridden by my 
  55. >subclass (I inserted the question marks).  I did not override them because 
  56. >they were not in the WinStat.idl file on the DR4 CD.  Am I correct in 
  57. >assuming that this is what is causing the problem?  If so, is there an 
  58. >updated idl file that I can get?  If not, does anyone have any suggestions 
  59. >about what is causing this problem?
  60.  
  61. The problem is that not all of the functions that are defined in the 
  62. WindowState (and probably other "patchable" objects as well) are in the 
  63. public .idl/.xh file.  You might notice that there are some "reserved" 
  64. entries in the idl.  These are actually used in the private version of 
  65. the idl file for functions like the ones you mentioned.
  66.  
  67. Also, beause of the way patching must work, it is necessary for the 
  68. patching object to implement _all_ of the functions of the patched object 
  69. and dispatch all of the calls on through to the original object.  This 
  70. means that in order to write a patch you'll need access to the private 
  71. idl and xh files.  I don't know if there is an approved mechanism to get 
  72. those files from Apple or not.
  73.  
  74. Also, note that if you write a patch, you have to be careful to make sure 
  75. that the patch is only for the current version of the class that you are 
  76. patching and that it will not be installed if there's a newer version of 
  77. OpenDoc with a new version of that class.  The reason this is important 
  78. is that if we add a method to, say, ODWindowState in a new version, your 
  79. patch won't know about that new method and cannot dispatch it to the 
  80. original WindowState object, so things will break/crash.
  81.  
  82. The upshot is that patching should be avoided as much as possible because 
  83. it is a _very_ limited solution.  If you depend on a patch and a user 
  84. upgrades to a newer version of OpenDoc (with a change like this) the 
  85. patch will stop working and so will your product.
  86.  
  87. I was one of the first people to write a patch for OpenDoc here, and I 
  88. discovered these problems.  Unfortunately, there was not time to do 
  89. anything about them.
  90.  
  91. >By the way, I did this same thing replacing the ODDispatchModule that 
  92. >handles menu events, and everything works fine.
  93.  
  94. Dispatch modules are designed to be extensible in this way (that is, 
  95. developers are expected to be able to implement their own or 
  96. replacements), so there shouldn't be a problem with it.
  97.  
  98. _troy
  99.  
  100. ......................................................................
  101.  Troy Gaul                                            tgaul@apple.com
  102.  Apple Computer, Inc.                    OpenDoc Added Value Products
  103. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
  104.  
  105.  
  106.  
  107.